[レポート]Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARM – CODE BLUE 2021 #codeblue_jp

CODE BLUE 2021で行われた「Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARM 」というセッションのレポートです。

#CODE BLUE

#CODE BLUE 2021

#セキュリティ

臼田佳祐

2021.10.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

今回はCODE BLUE 2021で行われた以下のセッションのレポートです。

Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARM

2017 年 Microsoft は ARM 版 Windows を発表した。 ARM 版 Windows を搭載した端末は Surface Pro X シリーズや HP ENVY x2 など増加傾向にあり、徐々に普及しつつある。

これらの ARM 端末を利用するにあたっては、既存の x86/x64 向けアプリケーションが利用できないという互換性の問題が生じる。しかし、x86/x64 エミュレーション機能の提供によりこの問題は対処されている。近年では、ARM64EC が発表され、段階的な x64 アプリケーションの ARM 移行も可能となった。こうした互換性テクノロジーの積極的な導入は Microsoft による ARM 版 Windows の普及促進の強い意志の表れと言える。

一方で、新しい互換性テクノロジーの登場は攻撃者にとって新しい攻撃の手段を提供することにはならないだろうか ? われわれの知る限り、この点は現時点でほとんど議論すらされていない。そこで、われわれは ARM 版 Windows に存在する互換性テクノロジーをリバースエンジニアリングし、その悪用可能性について検討を行った。

その結果、XTA cache ファイルを改ざんすることによるコードインジェクション・新規に導入された再配置エントリーを悪用した難読化手法など種々のテクニックが利用可能であることがわかった。これらの手法は、共通してバイナリの"見た目"と実行時の挙動が異なるという特徴を持っており、検知や追跡が困難な手法となっている。加えて、一部の手法は静的解析の妨害・サンドボックスでの解析の妨害として使えるなど幅広く悪用可能となっている。そのため、将来的に ARM 版 Windows において脅威となる可能性が高いといえる。

本発表ではわれわれが提案する新手法の詳細とその特徴についてデモを交えながら解説する。本発表を契機とし ARM 版 Windows のセキュリティ研究が発展・促進されることを期待する。

PoC コードと詳細なリバースエンジニアリング結果は GitHub にて公開する。

Presented by : 中川恒 - Koh Nakagawa

レポート

ARM版Windowsの話
ARM WindowsやM1 Macのリバーシングをしている
ARMはスマホやタブレットだけではなくPCにも使われるようになった
- Surface Pro Xとか
- M1 Macとか
- 発表に使っているものもARMベース
なぜARMが増えているか
- ARMプロセッサが電力効率がいい
- バッテリーがもつ
- スマホのようにノートPCを使えるようにしたりしている
- ニューノーマルではこの特性が重要
- バッテリー駆動時間が長いことは需要が高い
ユーザーがARMベースに移り変わるための障壁
- 互換性
- ARMに持ってきてそのまま実行はできない
- 様々な互換性テクノロジーが導入されている
- バイナリ変換と補完
  - 変換処理は重い
  - 高速化のためにキャッシュがつくことが多い
  - それでも重い
- 近年ではハイブリッドバイナリという技術もある
  - ネイティブ同等の速度にできる
  - 後ほど詳細を説明
- Fat Binary
  - 複数のアーキテクチャのバイナリを組み合わせる
  - 1つのバイナリを複数のアーキテクチャで使える
それぞれの実装がある
互換性テクノロジーが攻撃者に悪用されないのか
- 悪用された事例がある
- ARM WindowsやM1 Macではあまり議論されていない
- そもそも情報が少ない
- リバーシングの情報も少ない
今回の研究
- 互換性テクノロジーと攻撃手法について
- ARM版Windowsについて扱う
その前にちょっとだけMacの話
- Rosetta 2のリバーシング結果をまとめている
- githubとかにある
- 興味があれば見てみてね
バイナリ変換
- XTAJIT
- キャッシュXtaCache
- 同じアプリを実行したらパフォーマンスが向上する
x86/x64エミュレーションのDLL
- xtajit.dll/xtajit64.dll
- XtaCache.exe
- マップとかを行う
- エミュレーションがどうやって行われるか
  - イメージがロードされるとファイルハンドルがxtacacheが受け取る
  - ヘッダの情報を使ってキャッシュを検索する
  - 該当するキャッシュを見つけたらメモリにマップされる
  - 変換結果がなければjitでバイナリ変換してヒープに展開
- XTA Cache File
  - XtaCacheフォルダにある
  - xtachacheには通常ユーザーはアクセスできない
  - 管理者権限で変更可能
  - ファイルフォーマットは割愛
  - BlackHatの資料を見てね
  - パーサとかARM64コードを解析するツールもgithubにある
- XTAファイルの構造
  - Translated codeのところ
  - 難読化されていない機械語が含まれている
  - 逆アセンブラに入れれば命令列を見れる
  - ここのコードを改ざんしたらどうなるか
- 改ざんしたエミュレーション
  - 動く
  - 完全性を確保していない
  - コードインジェクションになる
  - XTA Cache Hijackingと呼んでいる
    - 実行時に検知が困難
      - 一度改ざんしたら通常のエミュレーションで実行できる
      - 正規の流れと同じ
    - 追跡が困難
      - 元となるPEに痕跡が見当たらない
    - 永続性を持っている
      - ファイルで永続化されている
- XTA Cacheを改ざんする必要がある
- 管理者権限を取得してこんな攻撃をする価値があるのか？
  - ある
  - Invisible Executionと呼んでいる
    - 隠蔽して別のコードを実行できる
    - コードフック
      - 通常は関数の一部の機械語を書き換える
      - 検知が可能
    - 痕跡を残さずコードフックできる
- 対策
  - XtaCacheディレクトリの権限の変更の監視や制限
- ここまでのまとめ
  - XTAJITやXTA Cacheをリバーシングしてフローを確認した
  - XTA Cache Hijacking
Hybrid Binary
- CHPE
  - 特殊なPE
  - x86とARM64双方のコードを含む
- x86PEと互換性を保ちつつ高速に実行できる
  - 見かけ上x86PEとなる
  - 逆アセンブルしてもx86の命令列
  - export thunkと呼ばれる
    - ARM64コードのジャンプスタブになっている
    - export thunkからjumpしてARM64のコードに移る
- ARM64EC
  - CHPEのx64拡張
  - CHPEとの違いはSDKが一般向けに公開されている
  - 今年の6月公開
- 1つのプロセス内でx86PEと混在して使える
- CHPEやARM64ECから外部を呼び出す時
  - CHPEなどからx86/64を呼び出す
    - 呼び出し規約の変更が必要
  - CHPEなどからCHPEなどを呼び出す
    - 呼び出し規約の変更などは不要に見える
    - 実は不要ではない
      - CHPEからMessageBoxAを呼び出す例
      - export thunkのアドレスになっているので変更する必要がある
      - じつは結構スキップできる
      - スキップできたら高速化できる
      - IATが用意されている
    - Hybrid Auxiliary IAT
      - export thunkのジャンプ先に書き換える
      - 呼び出し規約の変更などをまるまるスキップできる
- IAT hookingが2つ
  - Hybrid Auxiliary IAT hookの対応
  - 不整合があったら検知する
  - githubに公開している
FAT binary
- ARM64X
  - 双方のバイナリを含む
  - 新規のフォーマットではない
  - RAM64PEと表示される
- 特徴
  - EXEとして実行した場合親プロセスによって実行されるコードが違う
    - x86から実行はARM64
  - DLLとして使ったらすべてのプロセスからロードが可能
    - ARM64 / ARM64EC / x64でも
    - 奇妙な状況
    - メモリにロードされた表層情報がどうなっているか確認した
      - ARM64ECなどからみると表層情報が変わっている
      - 特定のプロセスからみるとそう動く
- IMAGE_DYNAMICRELOCATION_ARM64X
  - 動的なパッチが動く
  - DVRT ARM64X
    - 公式には構造が公開されていない
    - ARM64Xでググればドキュメントが出てくる
  - 再配置プログラムが3つ
  - Machine情報が動的なパッチで書き換えられる
- 実行時の柔軟な書き換えがされることを利用して難読化できないか
  - junkとなるデータを入れてDVRT ARM64Xを悪用
  - デコードした上でコードを実行させる
  - Packerが実装できた
  - 再配置により有効なコードを展開して実行できる
  - メモリダンプで解析できるのでは？
    - 工夫すれば妨害できる
    - 逆アセンブルされたらNullにする
- ARM64X特有の対解析
  - ARM64ネイティブ向けの領域に展開する
  - 逆アセンブルできないけど実行できる状態
  - x64として逆アセンブルすると有効
  - ARM64ECとして実行するときにx64として解釈して実行
  - WinDbgではARM64として解釈
  - 逆アセンブルできないけどステップ実行ができる
- 対策
  - Ghidra scriptを配布している
  - unpackしたあとのファイルを保存して解析
まとめ
- ARM版Windowsの解析結果と悪用手法を紹介した
- 発表されて間もない技術
- 十分に研究されつくしてない
- 他にも手法があるかも
- 今回のコンセプトは応用が可能
- 他の互換性にも利用できる
- 広く普及する前に研究していく必要がある